No worries. Sorry to trouble you. Cheers, Cameron

Thank you, Cameron

Thank you. I've reviewed the diff and they look like improvements across the board.

I do, though I'm open to rephrasing to make it clear that this isn't something which only `pip` can do. What I specificly wanted to achieve was to hook an action the reader is almost certainly very familiar with (`pip install`) to its place in the flow. How about: For example, when an end user runs ``pip install`` to install packages, :ref;`pip` is performing these last 2 steps. Is there a second example tool commonly used to install local packages we could also mention? i wanted it up the front here where the last 2 steps are in front of the reader's eyeballs. Cheers, Cameron Simpson ***@***.***>

Thank you, that looks great. Cheers, Cameron Simpson ***@***.***>

Thank you! - Cameron Simpson ***@***.***>

I see that we like full sentences in bullet lists, and the Oxford comma :-) And folding at a line length instead of a sentence/phrase break.

Reading the diff now. Short summary: I like almost everything you've done. My only objections are: Under "To use the package, end users must:" you've dropped "These last 2 steps are typically performed by a tool like `pip`_.". I think that's important and concise context, since many (most?) users will already be familiar with using pip to fetch packages. I wanted it apparent that when they did that familiar action, they're doing these last 2 steps. The better to hook this to their mental model and experience. TODOs: - I deliberately avoided "build backend"; there's already confusion between a build front end (which I take to be something you directly invoke, such as a command line) and a build back end (which I take to be an API compliant with the PEP so that things like "pip" can run it directly). To the new user, this is conceptual noise. They'll be using a build tool (setuptools, flit, whatever) and this is about the process around embedding their chosen tool in their distribution flow. So I prefer "build tool" at this point. - Link to tools: are you suggesting that where there's a tool specific entry in key_projects.rst we should point to it instead of (eg) a PyPI or github link? If so, I am all for it - the links I've found were merely the most apt I could see. - I don't have an opinion on hatchling vs flit, just that there should be at least 2 examples to show that you can use any compliant build tool in [build-system]. I could argue that it is good to use hatchling if the tutorial uses it, or good to use flit to show that the tutorial isn't the Only Way. - "build system" vs "build frontend"; see, I thought pip would fetch a module containing a build _backend_. Confusion already. I'd go for saying "build tool" once more. Or, given the TOML table name, "build system" throughout instead of "build tool". However, I think "build tool" is a more approachable term; to my mind it feels like something one can just fetch and use versus "build system" which feels to me more like a bulky framework one must work within. I agree with dropping mention of the stub `setup.py` if that is truly redundant these days; a stub seemed to be recommended when I wrote this stuff. It is definitely confusing extra noise for this document. I have mixed feelings about mentioning virtual environments. That's very much an end user thing instead of a publisher thing. And there are so many choices! For example, I'm still using "python3 -m venv" because I have yet to see what value something like pipenv brings :-) Maybe a rider paragraph right at the end mentioning that there are several flavours of "Python environment" end users may be using, with some of the links you mention. I would want to make it clear that the package _author_ should not need to care how the end user manages their Python environment. Without that clarification, authors/publishers have an additional (and needless) mental burden when preparing their packages. I know extraneous things like this mentally burden me when coming to a new area.